Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support oauth2 authentication for pulsar-client-go #313

Merged
merged 11 commits into from
Jul 15, 2020

Conversation

zymap
Copy link
Member

@zymap zymap commented Jul 8, 2020

Motivation

Support oauth2 authentication for pulsar-client-go

EronWright and others added 3 commits July 5, 2020 17:27
- based on cloud-cli @ bc645b16ca7b7474b132ee1da8b56da35025a616
Copy link
Member

@sijie sijie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @zymap and @EronWright for contributing this feature! The overall change looks good! A few questions:

  1. It seems that most of the tests are unit tests. Can we add some integration tests?
  2. Can you create an issue in https://github.com/apache/pulsar to document this feature in go client page?

Comment on lines 62 to 65
func NewAuthenticationOAuth2(
issuer oauth2.Issuer,
store store.Store,
oauth2Type, keyFilePath string) (Provider, error) {
Copy link
Contributor

@EronWright EronWright Jul 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that you changed this constructor from NewAuthenticationOAuth2(issuer, store) to NewAuthenticationOAuth2(issuer, store, oauth2type, keyfile). Let me explain why I think that's not a good change.

The authentication provider requires an authorization grant to be able to obtain access tokens over time. The grant is a long-lived credential, such as a keyfile or a refresh token. In all cases, the +application+ obtains the grant beforehand and then stores it in a store. The store might be persistent. Later, the application creates an authorization provider with the store as a parameter. The provider loads the grant from the store, and uses it over time to obtain access tokens.

I am trying to explain that the provider is not responsible for obtaining or storing new grants. Hence the signature NewAuthenticationOAuth2(issuer, store).

Now we discuss the special case of initializing the provider from parameters - NewAuthenticationOAuth2WithParams. One could imagine a combination of parameters that would open a pre-existing store but this would require more design work. A simple scenario that is possible now is the keyfile scenario in combination with an in-memory store (where the access token would be discarded when the process terminates). This scenario is implemented in NewAuthenticationOAuth2WithParams.

Would you revert the change to this method that is seen in 97d98f7?

EronWright and others added 5 commits July 10, 2020 00:57
Copy link
Contributor

@EronWright EronWright left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for integrating all the changes!

go.mod Outdated
github.com/sirupsen/logrus v1.4.1
github.com/spaolacci/murmur3 v1.1.0
github.com/spf13/cobra v0.0.3
github.com/spf13/pflag v1.0.3 // indirect
github.com/stretchr/testify v1.4.0
github.com/yahoo/athenz v1.8.55
k8s.io/utils v0.0.0-20200619165400-6e3d28b6ed19
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This dependency was due to the mock clock right? I recall that you forked it elsewhere, would that work here too?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Let me replace it.

@wolfstudy wolfstudy self-requested a review July 15, 2020 02:16
Copy link
Member

@wolfstudy wolfstudy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes LGTM+1, @zymap Can you fix @EronWright comments?

michaeljmarshall pushed a commit that referenced this pull request Aug 12, 2022
* remove oauth2 module

This removes the module definition in the oauth2 subdirectory.  Since the oauth2 module
is not released independently of the main module, it can/should be treated as a normal
module subdirectory.

Signed-off-by: Paul Gier <paul.gier@datastax.com>

* update tests for newer golang oauth2 dependency

Signed-off-by: Paul Gier <paul.gier@datastax.com>

* oauth2: add note to readme about possible module error

Signed-off-by: Paul Gier <paul.gier@datastax.com>

Signed-off-by: Paul Gier <paul.gier@datastax.com>

### Motivation

When the oauth2 sub-directory was added in PR #313 there wasn't any justification given (AFAICT) for creating a separate sub-module instead of just treating the oauth2 sources as a normal directory.  Since the oauth2 module does not have a separate release cycle, treating it as a sub-module just adds unnecessary complexity.

### Modifications

Removed `go.mod` and `go.sum` from the oauth2 sub-directory.  Updated the main `go.mod` and `go.sum` to included the necessary dependencies.

The main module contained a newer version of `golang.org/x/oauth2` dependency than the oauth2 sub-module, so I had to update some of the tests to match the output of the newer dependency.  This type of dependency mismatch will be avoided in the future using a single module defined in the root directory.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants